Simplify repetitive YAML of 'PublishBuildArtifacts' using default values #7101
Conversation
davidstaheli
changed the title
| "required": true, | ||
| "helpMarkDown": "The folder or file path to publish. This can be a fully-qualified path or a path relative to the root of the repository. Wildcards are not supported. [Variables](https://go.microsoft.com/fwlink/?LinkID=550988) are supported. Example: $(Build.ArtifactStagingDirectory)" | ||
| }, | ||
| { | ||
| "name": "ArtifactName", | ||
| "type": "string", | ||
| "label": "Artifact name", | ||
| "defaultValue": "", | ||
| "defaultValue": "artifact", |
There was a problem hiding this comment.
In the designer templates I spot checked, the artifact name is defaulted to "drop". Can we standardize on that?
There was a problem hiding this comment.
@hashtagchris thanks for checking that! Yes, let's use the same name in both places. Somehow, "drop" is vague to me. Internally we refer to "build drops", but is that old school, and what's common elsewhere? Since they're called "build artifacts," I thought "artifact" would be better. But maybe I'm wrong. Is "drop" more meaningful to people?
There was a problem hiding this comment.
I think "drop" was used to signify build drop. We should check if changing this will have an undesirable impact on the UI or elsewhere
There was a problem hiding this comment.
If we're going to change the default, what do you think of "build"? App Center has this:
I think having the default name "artifact" may make it harder to communicate that there are multiple artifact categories and that you can publish multiple build artifacts. Here's what you would get with our .Net Desktop template:
Also the artifact name is used in file paths for unc shares and downloads, and 8 characters puts us closer to the 260 character file limit. Admittedly having "build" in those file paths may be a bit odd: \myshare\builds\20180401.01\build\Release\ConsoleApp1.exe
There was a problem hiding this comment.
Agree "artifact" seems overloaded and will create confusion. "drop" is a fairly common term to indicate a build output.
There was a problem hiding this comment.
Thanks for your research and thoughts on this. I'll leave it as drop unless @jerickmsft has an opinion on it.
| "required": true, | ||
| "helpMarkDown": "The folder or file path to publish. This can be a fully-qualified path or a path relative to the root of the repository. Wildcards are not supported. [Variables](https://go.microsoft.com/fwlink/?LinkID=550988) are supported. Example: $(Build.ArtifactStagingDirectory)" | ||
| }, | ||
| { | ||
| "name": "ArtifactName", | ||
| "type": "string", | ||
| "label": "Artifact name", | ||
| "defaultValue": "", | ||
| "defaultValue": "artifact", |
There was a problem hiding this comment.
I think "drop" was used to signify build drop. We should check if changing this will have an undesirable impact on the UI or elsewhere
| @@ -21,15 +21,15 @@ | |||
| "name": "PathtoPublish", | |||
| "type": "filePath", | |||
| "label": "Path to publish", | |||
| "defaultValue": "", | |||
| "defaultValue": "$(Build.ArtifactStagingDirectory)", | |||
There was a problem hiding this comment.
Not all tasks will output to the artifact staging directory, so having a default that may not work is not a good idea. It is better to leave it empty since default of $(System.workingdirectory) is more likely to work for most tasks.
There was a problem hiding this comment.
I'll propose it's okay to default this value for when artifacts are in the Build.ArtifactStagingDirectory folder. Then, people only have to change it if they depart from the prescribed pattern. ArchiveFiles does this by defaulting its rootFolderOrFile input to $(Build.BinariesDirectory). When it comes to artifacts, the following tasks default to Build.ArtifactStagingDirectory: DotNetCoreCLI, DownloadBuildArtifacts, AppCenterTest, HelmDeploy, NuGetCommand, and DownloadPackage. So this change would make PublishBuildArtifacts more in harmony with those too. Also, our build templates already default the PublishBuildArtifacts task to use this value.
There was a problem hiding this comment.
If we want people to be selective with what they publish to the service, I think it would be good to either make **\*.
FWIW, if you publish $(Build.ArtifactStagingDirectory) without copying any files to it, your build succeeds with a warning from the agent: ##[warning]Directory 'D:\a\1\a' is empty. Nothing will be added to build artifact 'drop'.
|
BTW, @ericsciple recommended we use the major version bump as an opportunity to rename the task to PublishDropArtifact since it should work with release as well. See mortezag#2 |
|
@hashtagchris it matters less if you have a first class alias in yaml |
Each of our YAML templates has to repeat this common block:
All of the above inputs are required. This PR simplifies them by adding default values. I don't think this is a change in behavior that calls for a major version bump. The resulting YAML looks like: